Ham Radio 2000/Ham Radio 2000.iso/ham2000/packet/btb/btb.doc

Text File | 1992-07-18 | 8KB | 152 lines

                              GENERATION OF
                      "SELF-EXTRACTING" BASIC FILES

                        by Giuliano Artico I3LGP



   1. Transformation of a binary file into a basic program.

   The problem of transforming a binary file into a form compatible with
the trasmission via packet radio as a text file leaded to the production of
several programs which perform such function in a more or less efficient
way.
   The primary requirement of a software of this type is reducing the size
of the output file as most as possible to diminish the channel occupation
during the transmission. For this reason, some programs employ
compression algoritms whose complexity causes an augmentation of the size
of the extracting routine, which therefore cannot be incorporated in the
transmitted file.
   Of course, the ideal capability would be reached if everyone would use
the same encoding program, the one with the greatest efficacy:
consequently, however, all potential users ought to retain such program in
order to decode received texts.
   Reaching such an aim seems to be quite difficult, since there exist
several different programs with good characteristics. Therefore a simpler
solution may sometimes provide satisfactory results: converting a binary file
into a "self-extracting" program, which is divided into two parts, the
decoding routine and the text to be converted. The easiest language is
BASIC, but other ones might be adopted.
   The BASIC program I propose in the present note generates a auto-
rebuilding BASIC file, asking for a binary file to be processed in the
encoding phase. Once the output file has been produced, it may be run
(e.g., under GW-Basic) and the original binary file is reconstructed.
   In writing the program, I estimated opportune to choose an encoding
method which balances length of extracting routine with the total size of
stored data. The very easiest method for the conversion is storing in the
data section all the ASCII or hexadecimal codes of bytes picked up from
the binary file: this allows decodification by means of a very low number of
instructions, but the amount of spaceoccupied by data is between twice and
three times the size of the original file.
   Therefore I adopted the "six-bit" encoding method, which converts a
sequence of three bytes into a sequence of four characters: consequently
the resulting text is one third greater than the size of the given binary
file. Also in this case some space is occupied by line numbers and sintax
words.
   To understand how the conversion algoritm works, consider that a
sequence of three bytes may be represented as follows:

                       ******** ******** ********

where every '*' represents the position of a bit in its byte. We have a
string of  24 bits, which may be splitted into four sequences of six bits:

                       ****** ****** ****** ******

Since the six positions of such a sequence may be occupied either by 0 or
by 1, each of them allows 2^6=64 dispositions. The algoritm has just to
establish a correspondence between every such a disposition and a
character, taken among the ones that may be sent via packet radio in the
text form, that is the ones whose ASCII code is between 32 and 126. I
chose the character set ranging between # (ASCII 35) and b (ASCII 98) to
skip " which is the string delimiter in BASIC.
   I obtained such correspondence by using the logic operators AND and
OR and the operations * and \, applied in a suitable way to the decimal
ASCII code of input bytes. Every ASCII code is an integer number between
0 and 255 that may be represented as a sequence of eight digits 0 or 1. For
instance, suppose you are given a byte whose ASCII code is 183 and
observe the following table:

         183  =  1 0 1 1 0 1 1 1
         252  =  1 1 1 1 1 1 0 0
 183 AND 252  =  1 0 1 1 0 1 0 0  =  180

The third line contains the result of the operator AND applied to numbers
183 and 252: in every position we put the smallest between the two digits
occupying the same position in the two superior lines. In other words, we
have extracted the first six bits of the given byte binary representation by
performing the operation AND between the given number and the number
252. Similarly, denoting the ASCII code by x, we may extract the first
four bits of its binary representation by "x AND 240", the last four bits by
"x AND 15", the last two bits with "x AND 3" and so on.
   We have not space enough for further details. Just let's say that the
operator OR allows to join together two previously extracted fragments of
byte if they are disjoint from each other, that is if the operator AND
applied to them gives 0 as result.
   The aritmetic operations * (multiplication) and \ (integer division) are
used to "shift" a "piece of byte" towards left side and right side
respectively.

   2. Description of the code.

   BTB.BAS (BinToBas) and files generated by it may either be run under
GW-Basic or be compiled with Quick Basic or Bascom.
   I suggest to use a compiled version since it allows to enter input file
and output file names as parameters on the DOS command line when BTB is
run. Furthermore, the syntax of the command line and a short help may be
also obtained by typinga '?' as argument at the DOS prompt.
   Notice that in compiling BTB it is necessary to invoke options /E (ON
ERROR) and /X (RESUME).
   Essentially, the code consists of sub-routines 2000, 3000, 6000 and 7000.
   Sub-routine 2000. If the variable COMMAND$ is different from the null
string, then the first two parameters are extracted from it. The first
parameter is assumed as the name of the source binary file (input file) and
the second one as the name of the target file (basic program).
   Sub-routine 3000. If the source file name has not been entered on the
DOS command line, then the program asks for it. Subsequently, if the
target file name is missing, then it is obtained from the name of the source
file by replacing its extension with ".BTB" (routine 5000). Then the program
checks the existance of both files. If the binary file does not exist then a
new name is requested but if the name has been supplied at the DOS
prompt then the control is returned to DOS. If the target file exists then a
question is put wether to overwrite it or not, to guard against its deletion.
   Sub-routine 6000. It writes to the output file the extracting routine,
which will re-build the original binary file. Such routine performs some
controls which are described below.
   Sub-routine 7000. This is the encoding phase: strings of 51 bytes are
taken out from the input file and converted to a text line of 68 characters
with the procedure delineated above. A check sum is computed for every
line and converted to a byte which is put at the end of the line and then
every line is stored in the target file. A total check sum is calculated and
written as the last data line of the file.

   3. Files generated by BINTOBAS.

   The extracting routine consists of the first 20 lines of BASIC files
generated by BINTOBAS. Its total length is 1077 bytes. It verifies the
existance of a file with the name that is stored at line 20 and exits if
such file is present.
   Some controls are performed to ensure that the resulting binary file
matches the original one:
   a) the size of binary file and the number of data lines must be
coherent with each other: also this values are contained in line 20;
   b) length of data strings must be greater than or equal to 69 (all
characters following the 69th are skipped);
   c) the 69th byte in every DATA string (except the last one) is a "local
parity control" which is used to ensure the correctness of that string;
   d) character ASCII code must be in the correct range (ASCII 35 to 98);
   e) finally, check sum must be identical to the one stored in the last
data line.
   If any of the previous conditions is not satisfied, the routine exits with
an error message.
   The resulting file is identic to the original one: no <CTRL-Z> character
is added at the end, since a random access file is used for output.

Address: Giuliano Artico
         Dipartimento di Matematica Pura e Applicata
         Via Belzoni 7, 35131 Padova, Italy
Phone  : [phone]
E-mail : Internet = [e-mail]    Decnet = 38999::ARTICO